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Abstract 

Proposed  extensions  of  the  ML  type  system  to  incorporate  global 
overloading  include  the  systems  of  [Kae88,  CD091,  Smi91,  Kae92, 
Jon92]  and  those  related  to  the  design  of  the  functional  programming 
language  Haskell  [WaB89,  CH092,  NiP93].  These  systems  have  in 
common  the  notion  of  a  constrained  type  scheme  which  in  some  is 
realized  by  type  kinds  and  in  others  as  explicit  predicates.  An  analysis 
of  these  type  systems  reveals  that  some  are  unsound  with  regard  to 
a  suitable  criterion  for  typability  and  some  adopt  a  notion  of  type 
generality  that  is  inconsistent  with  that  of  system  ML  [DaM82]. 

1     Introduction 

Much  of  the  research  in  type  theory  is  devoted  to  finding  new  type  systems 
that  offer  programmers  more  flexibility  without  compromising  the  advantages 
of  a  strongly-typed  language.  One  of  the  simplest  type  systems  is  Ao,  the 
implicit,  finitely- typed  lambda  calculus  [Tiu90,  BaH90].  It  assigns  finite 
types  to  type-free  A  terms.  For  example,  in  Ao  one  can  derive  the  typing 
h  Ax.  x  :  a  —*  a.  In  fact,  one  can  derive  h  Ax.  x  :  r  — ►  r  for  any  finite  type 
r.  Consequently,  Ax.  x  can  be  assigned  multiple  types  within  a  single  term 
as  is  necessary  in  deriving  a  type  for  (Ax.  x)  Ax.x  in  Aq. 


Although  A0  allows  a  term  denoting  a  polymorphic  value  to  be  assigned 
multiple  types,  it  does  not  allow  a  free  identifier  that  denotes  such  a  term 
to  be  given  multiple  types  within  a  single  A  term.  For  example,  the  term 
(Ay.  y  y)  Ax.  x  is  untypable  in  A0  even  though  y,  which  is  free  in  y  y,  denotes 
Ax.x.  So  although  Ao  has  desirable  properties  like  a  decidable  typability 
problem  and  principal  types  for  all  typable  terms,  it  is  for  the  most  part 
unsuitable  for  direct  use  in  a  programming  language. 

This  limitation  was  overcome  in  the  ML  type  system  [Mil78,  DaM82] 
which  is  an  extension  of  Ao  with  type  schemes.  A  type  scheme  represents  a 
very  simple  kind  of  polymorphism  called  parametric  polymorphism.  A  free 
identifier  may  be  asserted  to  have  infinitely  many  types  via  a  type  scheme. 
However,  in  the  interest  of  retaining  principal  types,  lambda  abstraction 
in  system  ML  is  monomorphic  as  in  Ao-  Thus  (Ay.  y  y)  Ax.  x  is  untypable  in 
system  ML  as  well.  How  then  does  system  ML  allow  free  identifiers  denoting 
polymorphic  values  to  be  assigned  multiple  types?  Only  through  its  let 
construct.  So  for  example,  (Ay.  yy)  Ax.  x  is  written  let  y  =  Ax.  x  in  y  y. 

Like  A0,  system  ML  has  a  decidable  typability  problem  and  typable  terms 
have  principal  types.  Further,  it  seems  to  offer  an  acceptable  level  of  flexibil- 
ity as  evidenced  by  its  incorporation  in  languages  like  Standard  ML  [HMM86] 
and  Miranda  [Tur86].  Yet  it  remains  limited  in  some  ways  that  appear  to  be 
solely  of  theoretical  interest,  and  in  others  that  are  very  obvious  in  practice. 

One  practical  limitation  is  that  it  prohibits  overloading  by  restricting  to 
at  most  one  the  number  of  assumptions  per  identifier  in  a  type  assumption 
set,  a  limitation  noted  by  Milner  himself  in  [Mil78].  Suppose  we  wish  to 
assert  that  a  free  identifier,  say  +,  has  precisely  finite  types  int  — ►  int  —*■  int 
and  real  —>  real  — ►  real.  Any  assumption  set  in  which  +  has  one  of  the  two 
desired  finite  types  precludes  a  derivation  that  it  has  the  other.  On  the  other 
hand,  any  assumption  set  that  assigns  type  scheme  Va.a  — ►  a  — *  a  to  + 
is  one  from  which  too  many  types  can  be  derived  for  +.  Thus  there  is  no 
assumption  set  in  system  ML  from  which  we  can  derive  precisely  the  desired 
finite  types  for  +.  Even  system  ML  with  subtypes  is  inadequate.  From 

A  =  {int  C  real,    +  :  real  — ►  real  — *  real} 

one  could  derive  Ah  +  :  int  —*  int  — +  real  but  not  A  h  +  :  int  — *  int  — >  int. 
Many  extensions  of  system  ML  have  been  proposed  to  incorporate  over- 
loading. There  are  the  systems  of  [Kae88,  CD091,  Smi91,  Kae92,  Jon92]  and 
those  related  to  the  design  of  the  functional  programming  language  Haskell 


[WaB89,  CH092,  NiP93].  This  paper  reviews  these  systems.  As  we  shall 
see,  some  are  unsound  under  a  proper  notion  of  typability  and  some  even 
adopt  a  notion  of  type  generality  that  is  inconsistent  with  the  original  notion 
proposed  in  [DaM82]. 

2     Constrained  Type  Schemes 

The  terms  of  the  type  systems  we  consider  are  typical.  Every  variable  x 
is  a  term,  and  if  M  and  N  are  terms  then  so  are  Xx.M,  (M  N),  and 
let  i  =  M  in  N.  There  is  no  expression  that  overloads  identifiers  locally 
like  the  over  expression  proposed  in  [WaB89].  The  only  overloading  the  sys- 
tems attempt  to  address  is  that  which  comes  from  an  initial  basis  or  sequence 
of  top-level  definitions,  which  we  call  global  overloading. 

Each  system  has  the  same  set  of  finite  types  defined  in  the  usual  way. 
Every  type  variable  a  is  a  finite  type,  and  if  r1? . . . ,  rn  are  finite  types  then 
so  are  rx  — ►  r2  and  x(ri>  •  •  •  >  Tn)  where  x  1S  a  type  constructor  of  arity  n. 

The  systems  have  in  common  the  notion  of  a  constrained  type  scheme 
which  in  some  is  realized  by  a  type  of  types  called  a  kind  and  in  others  as  an 
explicit  predicate.  A  kind  is  a  universe  of  types  over  which  a  type  variable 
may  be  quantified.  Kinds  appear  in  [Kae88,  CD091,  CH092,  NiP93]  where 
the  general  form  of  a  constrained  type  scheme  is  Vc*  :  p.  a  for  some  kind  p. 
Explicit  predicates  appear  in  the  systems  of  [WaB89,  Smi91,  Jon92,  Kae92] 
where  the  general  form  of  a  constrained  type  scheme  is 

Vai, . . . ,  an  with  xt  :  rlf . . . ,  xm  :  rm .  r 

for  predicates  X\  :  r1,...,xm  :  rm.  Predicates  also  appeared  earlier  in  the 
work  of  Holmstrom  [Hol83] . 

Although  syntactically  different,  constrained  type  schemes  of  all  these 
systems  may  be  interpreted  as  Horn  clauses.  For  example,  suppose  multipli- 
cation (*)  and  the  multiplicative  identity  (1)  are  overloaded  in  a  type  basis. 
Then  if  both  were  free  in  a  definition  of  expon  that  raises  a  value  to  some 
integer  power  then  expon  should  have  as  types  r  — ►  int  — ►  r  for  any  finite 
type  t  for  which  predicates  1  :  r  and  *  :  t  —>  t  -+  t  are  true.  This  may  be 
expressed  by  a  constrained  type  scheme  using  predicates  as 

expon  :  Va  with  1  :  a,  *  :  a  — ►  a  — ►  a .  a  — ►  int  — *  a . 


If  Tx(r)  means  i  :  r  then  this  is  interpreted  as  the  Horn  clause 

Tespon(a  — ►  int  — ►  a)   <—   Ti(a)  A  T.(a->a->a). 

It  is  natural  to  consider  Horn  clauses  with  other  kinds  of  predicates  as 
well  expressing,  for  example,  subtype  inclusions  [Smi91,  Jon92,  Kae92]  and 
even  unification  among  finite  types  [Kae92].  The  latter  kind  of  predicate 
shows  that  typability  in  system  ML  is  actually  an  instance  of  typability  in 
a  predicate- based  system.  Of  course  in  system  ML,  the  absence  of  a  unifier 
implies  the  given  term  is  untypable  and  if  unification  succeeds,  then  a  uni- 
fying substitution  can  be  reflected  in  an  unconstrained  type  scheme,  so  no 
explicit  predicates  or  kinds  are  needed. 

3     A  Criterion  for  Typability 

When  is  a  term  typable  with  respect  to  a  set  of  type  assumptions?  One  cri- 
terion for  typability  often  used  for  system  ML  is  called  strong  type  inference 
[Tiu90].  Under  it,  a  term  M  is  typable  with  respect  to  an  assumption  set  B 
if  there  is  an  assumption  set  A  and  type  a  such  that  B  C  A  and  A  h  M  :  a 
is  derivable.  Thus  in  a  formulation  of  the  typability  problem,  M  and  B  are 
considered  input.  Yet  the  problem  only  requires  finding  an  A  that  contains 
B  so  there  is  considerable  latitude  in  the  choice  of  A.  In  fact,  within  the 
context  of  overloading,  there  is  too  much.  Consider  the  term  true  +  true, 
where  true  denotes  a  truth  value  and  +  integer  addition  as  conveyed  by  the 
assumption  set 

B  =  {true  :  bool,    +  :  int  — ►  int  — ►  int}  . 

Then  the  term  could  be  typable  under  B  in  a  sound  type  system  since  with 

A  =  B  U  {+  :  bool  -*  bool  -*  bool} 

we  can  derive  A  h  true  +  true  :  bool.  But  B  h  true  +  true  :  bool  is 
not  derivable,  since  +  does  not  have  an  instance  for  type  bool  within  B. 
Therefore  the  term  should  not  be  typable  under  B. 

Thus  a  suitable  criterion  for  typability  is  strong  type  inference  with  the 
requirement  that  B  h  M  :  a  be  derivable.  However  a  is  constrained  so  unless 
a  type  system  prevents  quantification  over  an  empty  type  universe,  it  may 
be  unsound  in  that  terms  with  domain  incompatibilities  are  typable. 


4      Soundness  of  the  Proposed  Systems 

The  early  work  of  Kaes  [Kae88]  led  to  an  extension  of  system  ML  based 
on  type  kinds.  It  permits  a  restricted  form  of  overloading  called  parametric 
overloading  which,  when  extended  to  allow  overloading  of  constants,  corre- 
sponds to  the  kind  allowed  in  Haskell.  Kaes  gives  a  type  inference  algorithm 
where  unification  is  done  with  variables  having  kinds.  This  was  later  discov- 
ered to  be  an  application  of  order-sorted  unification  in  [NiS91]  where  type 
inference  in  Haskell,  which  permits  overloading  via  classes,  is  implemented 
in  the  context  of  order-sorted  algebras. 

Kaes's  extension  has  two  kinds  of  assumption  sets,  one  for  ordinary  type 
assumptions  and  the  other  for  overloading  assumptions.  For  example, 

A       f  /:Va{/}.a{/}- 
1  9  ■  Vq;{5}-  aig)  ~ 

is  a  type  assumption  set  and 

o  =  l  f ''  (u  ~*  ^'  f"1*'  rcfl'})>   1 

|  g  :  (u>  — ►  cj,  {bool,  char})  J 

is  an  overloading  assumption  set.  Set  0  specifies  the  different  finite  types  for 
the  overloaded  identifiers  /  and  g.  The  types  of  /,  for  example,  are  formed 
by  replacing  uj  in  u>  — *  uj  by  int  and  real. 

A  type  variable  may  be  annotated  with  a  set  of  identifiers  that  effectively 
specifies  its  kind.  The  variable  ranges  only  over  those  finite  types  for  which 
all  functions  in  the  set  are  simultaneously  defined.  So  or/,  for  example,  ranges 
over  types  int  and  real,  but  not  bool,  with  respect  to  0. 

Under  the  strong  type  inference  criterion,  a  term  M  would  be  typable 
with  respect  to  A  and  0  in  this  system  if 

A,  0  \~  M  :  &    for  some  type  a. 

But  the  system  is  unsound  under  this  criterion,  for  even  though  O  specifies 
that  /  and  g  have  no  finite  types  in  common,  we  can  derive 

A,  0  h  Xx.  g{f  x)  :  Va{/,5}.  a{/tj}  ->  a{f,g} 


in  the  system: 

aU,9}  ~*  ai/,3}  <o  Va{/}.  a{/}  -*  Q{/}  (<„) 

A  U  {x  :  Q{/,a}},  Oh/:  ct{f<g}  ->  a{f<g}         (var) 

aif,9}  "•  q{/.j}  <o  Vq;{<7}-  <*{<;}  ~*  <*{<;}  (<o) 

4  U  {x  :  Q{/,g}},  0\~  g:  a{f<g}  -♦  q{/,5}  (var) 

AU  {s  :  <*{/,<,}},  0  h  g(f  x)  :  a{/i5}  (app)2 

A,  0  h  Ax.  #(/  x)  :  ay^  -»  a{/i5}  (abs) 

A,  O  h  Ax.  #(/  x)  :  Va{/iP}.  a{/i5}  -+  a{/i5}  (closure) 

In  essence  we  can  hypothesize  overlap  in  the  types  of  /  and  g  through  type 
a{/.5>  f°r  ^ne  sa^e  °f  showing  Xx.g(f  x)  is  typable,  yet  we  are  not  required 
to  show  that  any  overlap  exists.  Thus  a  type  can  be  derived  for  the  term 
under  A  and  O  even  though  the  term  has  a  type  incompatibility.  A  sound 
variant  of  this  system  is  given  in  [Rou90,  Kae92]. 

Parametric  overloading  prevents  certain  kinds  of  overbadings  like 

{+  :  int  — >  real  — »  real,  1 

+  :  real  — ►  complex  —*  complex  J 

which  is  useful  for  describing  mixed-mode  arithmetic.  In  an  attempt  to 
permit  more  general  kinds  of  overloadings,  Wadler  and  Blott  give  a  predicate- 
based  extension  of  system  ML  [WaB89].  But  like  [Kae88],  it  too  is  unsound 
under  strong  type  inference.  Further,  unlike  Kaes's  system  which  restricts 
overloading,  typability  in  their  system  under  a  revised  criterion  is  undecidable 
[VoS91].  A  restriction  that  allows  overloadings  for  mixed-mode  arithmetic 
and  for  which  typability  is  decidable  is  given  in  [VoS91]. 

The  type  system  ML0  described  in  [Smi91]  is  sound.  It  replaces  the  type 
generalization  and  instantiation  rules  of  ML  by  the  following  rules. 

(V-intro)  AUChM:r',    A  h  C[a  :=  f]       {a  Qot  {ree  in  A) 

AhM  :  Vd  with  C  .  r'  v  ; 

(V-elim)  Ar-M  :  Va  with  C.r',    Ah  C[a  :=  f] 

AhM:  r'[a  :=  f] 


To  illustrate  these  rules,  consider  a  term  M  =  Ax.  (x  +  x),  with  free  identifier 
+,  and  a  type  assumption  set  B  defined  as  follows. 


B  =  < 


+   :  int  — +  int  — *  int, 
+   :  real  -*  real  — *  real, 

<  :  c/iar  — >  c/iar  — ►  600/, 

<  :  Va  with  <  :  a  — *  a  — ►  600/ .  seg(a)  — »  seq(a)  —*  600/ 


We  show  a  derivation  of  B  h  M  :  Va  with  +  :  a  — ►  a  — *  a .  a— *  a  in  M£0. 

5U{+:a-»a->a}U{i:a}hi:a  (hypoth) 

5U{+:a- ►  a  — ►  a}  U  {x  :  a}  h  +  :  a  — ►  a  — +  a  (hypoth) 

5U{+:a^a-^a}U{i:a}h(i|i):a  (->-elim)2 

B  U  {+  :  a  — ►  or  — ►  a}  h  Ax.  (x  -f  x)  :  a  — ►  a  (— »-intro) 

5  h  {  +  :  a  — *  a  — »  a}  [a  :=  rea/j  (hypoth) 

5  h  Ax.  (x  +  x)  :  Va  with  +  :  a  — ►  a  — *  a.  a  — *  a  (V-intro) 

The  last  step  of  the  derivation  discharges  assumption  +  :  a  — »  a.  — ►  a  which 
was  used  to  derive  a  type  for  M,  making  a  type  derivation  possible  from  the 
initial  set  B.  Before  this  could  be  done  however,  we  needed  to  establish  that 
the  assumption  is  derivable  with  a  instantiated  to  some  finite  type  {real  was 
chosen  in  our  example  although  int  would  have  sufficed).  For  some  terms 
and  type  assumptions,  this  is  impossible.  The  term  M  =  Ax.  Xy.y  <  (x  +  x) 
together  with  B  is  an  example.  We  can  hypothesize  a  type  assumption  set 
C  in  which  +  and  <  overlap  on  some  finite  type,  say  or,  by  defining  C  as 

C  =  {+  :  a  — ►  a  — ►  a,    <:  a  — ►  a  — ►  bool} 

and  then  derive  BUC\rM:a—>a—*  bool.  But  the  derivation  must  end 
here  because  there  is  no  finite  type  for  a  that  allows  us  to  derive  C  from  B, 
so  M  is  untypable. 

The  work  of  [CD091]  is  an  effort  to  relax  the  restrictions  of  a  parametric 
overloading.  They  give  a  kind-based  extension  of  system  ML  that  restricts  re- 
cursive overbadings  slightly  less  than  parametricity  and  for  which  typability 
is  decidable.  Yet  assumptions  for  mixed-mode  arithmetic  are  still  prohibited. 

The  system  however  is  sound  under  strong  type  inference.  It  is  interesting 
to  see  how  the  system  prevents  a  type  from  being  derived  for  term  Xx.g(f  x) 
when  free  identifiers  /  and  g  have  no  finite  types  in  common. 


Derivations  are  made  with  respect  to  a  traditional  type  environment  A 
and  a  kind  environment  T  that  maps  type  variables  to  kinds.  There  are  two 
operators  on  kinds,  fix  and  a  union  operator  U.  Kinds  are  partially  ordered 
by  a  containment  relation  <  such  that  JL  <  p  for  any  kind  p. 

The  type  instantiation  and  generalization  rules  of  system  ML  are  modified 
to  accomodate  constrained  type  schemes  with  kinds: 

(inst)  T;  A  h  M  :  Va  :  p.  a        ,—  »  <    . 

(gen) 


r; 

Ah  M 

Va  : 

p.  (j 

r; 

Ah 

M 

a  [a 

:=r] 

r, 

a  :  p\ 

A\-  M 

:  a 

T;  Ah  M  :Va:p.<j 


(a  not  free  in  A  A  p  ^  1) 


Here  T(t)  is  finite  type  r  with  all  free  type  variables  replaced  by  the  kinds 
prescribed  for  them  by  T. 
Suppose 

J  /  :  Va  :  int  U  real,  a  — ►  a,     1 
I    g  :  Va  :  600/  U  char,  a  — *  a  j 

The  only  way  we  can  hypothesize  any  overlap  between  /  and  g  is  through 
use  of  kind  _L  since  _L  <  p  for  any  kind  p.  Proceeding  in  this  way  yields 

{0:  1};  AU  {x:  13}  \- x  :  0  (var) 

r(/9)  =  _L    <    in*  U  real  (<) 

{/?  :  i.};  AU{i:/3}1-/:Vq:  hi*  U  rea/.  a -*  a  (var) 

{^:l};AU{i:^h/:^/3  (inst) 

r(/?)  =  JL   <   bool  U  char  (<) 


J_};  A  U  {x  :  0}  h  #  :  Va  :  600/  U  c/iar.  a  — ►  a  (var) 

IJiAUJzi^hj:^/?  (inst) 

l};AU{i:^h5(/i):^  (app)2 

X};  Ah  Xx.g(fx)  :  0 ->  0  (abs) 


The  generalization  rule  cannot  be  applied  at  this  point  to  discharge  the  re- 
maining kind  assumption  {0  :  J_}  so  Xx.g(f  x)  is  untypable  under  A. 

The  type  system  of  [CH092]  is  another  kind-based  extension  of  system 
ML,  that  unlike  [CD091],  is  unsound  under  strong  type  inference.  This  work 


is  not  an  attempt  to  relax  the  restrictions  of  parametric  overloading  but 
rather  to  formalize  a  type  system  for  Haskell  with  parametric  type  classes. 

Derivations  in  [CH092]  are  also  made  with  respect  to  a  traditional  type 
environment  A  and  a  kind  environment,  which  they  call  a  context  C,  mapping 
type  variables  to  kinds.  Kinds  here  are  taken  to  be  sets  of  class  names  T  with 
each  class  having  an  optional  finite  type  as  parameter.  So  for  example,  if  F 
and  G  are  class  names,  then  {a ::  {F,  G}}  is  a  kind  environment  that  asserts 
a  is  a  class  instance  of  F  and  G,  meaning  that  a  is  a  type  over  which  the 
operations  of  both  classes  F  and  G  are  defined. 

The  type  instantiation  and  generalization  rules  of  system  ML  are  replaced 
by  rules  (V-elim)  and  (V-intro): 

(V-elim)  A,  C  h  M  :  VarT.  <7         ,~„         ™ 

A,  C\~  M  :a[a:=T]       [  T"    ' 

(V-intro)  A,  C, or::  T  h  M  :  a  ,  .  c  .        ^ 

-r  7T-, — w    t, — s ia  not  free  m  «  or  C) 

A,  C\~  M  :  Va::r.a         v  ; 

where  C  H-  nrT  is  derived  using  a  set  of  entailment  inference  rules  with 
class  instance  declarations  £)  as  axioms.  For  example,  if  D  =  {int  ::F]  then 
0  H-  intr.F. 
Suppose  that 

D  =  {int::F,  real ::  F,  bool::G,  char::G} 

which  asserts  that  class  F  has  as  instances  finite  types  int  and  real,  and  class 
G,  types  bool  and  c/iar.  So  with  respect  to  D,  there  is  no  finite  type  over 
which  the  operations  of  F  and  G  are  defined.  But  with 

A=  f/:Va::{F}.a-,a,  1 
I   #  :  Va::{G}.  a  — ►  a    J 

we  can  derive 

A\-Xx.g(fx):Vfi::{FtG}.0^0 

in  the  system,  thus  establishing  that  \x.g(f  x)  is  typable  with  respect  to  A 
under  the  strong  type  inference  criterion  even  though  the  derived  type  scheme 


has  no  finite  types  as  instances  with  respect  to  D.  Using  kind  {F,  G},  we 
hypothesize  overlap  between  /  and  g  yielding  the  derivation 

AU{x:(3},  {/?::{F,G}}hx:/3  (var) 

{/?::{F,G}}H-/3::F  F  G  {F,G} 

{0::{F1Cf]}\h0::{F}  ( H-  ) 

A  U  {x  :  /?},  {0  ::  {F,  G}}  h  /  :  Va::{F}.  a  ->  a  (var) 

A  U  {x  :0},{0::  {F,  G}}  h  /  :  0  -  0  (V-elim) 

{/?::{F,G}}^/?::G  Gg{F,G} 

{/?::{F,G}}H- /?::{<?}  (  H- ) 

AU{x:0},  {0::{F,G}}\-g:Va::{G}.Q^a  (var) 

A  U  {x  :  0},  {0  ::  {F,  G}}  h  g  :  /?  -  0  (V-elim) 

AU{i:  0},  {/?  ::  {F,  G}}  h  *(/  x)  :  0  (A-elim)2 

A,  {0::{F,G}}r-\x.g(fx):>3-+?  (A-intro) 

A  h  Ax.  g{f  x)  :  V/?::{F,  G}.  0  -»  0  (V-intro) 

In  the  final  step,  the  entire  context  is  discharged  even  though  there  is  no  finite 
type  that  satisfies  it  with  respect  to  D.  An  almost  identical  derivation  can 
be  constructed  in  the  system  of  [NiP93]  and  in  the  predicate-based  extension 
of  system  ML  given  in  [Jon92].  With  a  minor  reformulation  of  A  and  D 
requiring  kinds  to  be  interpreted  as  predicate  sets  so  that  for  example  D  is 

{Fint,  F  real,  Gbool,  G  char} 
viewing  F  and  G  as  predicates,  one  can  derive  in  the  system  of  [Jon92] 

D\A\-  Xx.g{f  x)  :Va.{Fa,  G  a)  =>  a ->  a . 
Although  D  specifies  no  overlap  for  /  and  g,  we  can  prove  the  judgement. 

5     Type  Generality 

In  order  to  define  in  the  systems  considered  here  a  notion  of  principal  type 
among  derivable  types,  a  generic  instance  relation  is  needed  that  tells  us 
whether  one  type  is  more  general  than  another  [DaM82].  In  the  context  of 
constrained  type  schemes,  this  relation  becomes  a  preorder  rather  than  a 
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partial  order  since  two  distinct  types  can  each  be  a  generic  instance  of  the 
other. 

Some  of  the  proposed  type  systems  require  that  in  order  for  a  constrained 
type  scheme  a'  to  be  a  generic  instance  of  another  such  scheme  a,  it  must  be 
possible  to  replace  the  bound  variables  of  a  by  finite  types  so  as  to  make  the 
bodies  of  a  and  a'  syntactically  equal  [WaB89,  CH092,  Kae92,  Jon92].  This 
is  an  artifact  of  the  original  relation  of  [DaM82],  which  for  system  ML,  gives 
a  way  to  check  that  a  has  as  instances  all  finite  types  that  are  instances  of 
a' ,  or  in  other  words,  that  <7  is  more  general  than  a'.  However,  the  relation 
is  also  typically  defined  relative  to  some  form  of  assumptions  from  which  an 
attempt  can  be  made  to  show  that  a  finite  type  is  an  element  of  a  kind  or 
that  a  predicate  is  true.  Now  it  is  no  longer  appropriate  to  demand  syntactic 
equality  of  type  bodies  in  order  to  establish  that  one  constrained  type  scheme 
is  more  general  than  another. 

For  example,  in  the  system  of  [CH092],  constrained  type  scheme 

Va::{F}.V£::{.F}.a-»/3 

is  not  a  generic  instance  of 

V~f::{F}.  7  — ♦  7 

with  respect  to  any  set  of  class  instance  declarations  since  there  is  no  sub- 
stitution on  7  that  when  applied  to  7  — >  7  gives  a  — +  (3.  Yet  in  the  context 
of  a  single  declaration,  say  {int::F},  the  latter  type  does  indeed  have  as 
instances  all  finite  types  that  are  instances  of  the  former  (only  int  — »  int) 
and  is  therefore  more  general  in  this  context.  Similar  examples  can  be  given 
in  the  systems  of  [WaB89,  Kae92,  Jon92]. 
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